<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">
<head>

<meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<link REL="STYLESHEET" HREF="../../book.css" CHARSET="ISO-8859-1" TYPE="text/css">
<title>Tips For making user interfaces accessible</title>
</head>
<body>
<h1>Tips for making user interfaces accessible </h1>
<p>Below is a series of tips for making applications compatible with accessibility
programs, such as the Accessibility interface provided by Windows. </p>
<dl>
<dt><b>Use groups instead of labels.</b></dt>
<dd>If you use a <b>Label</b> to title a group of related widgets, remove the label and
  replace their parent composite with a <b>Group</b> whose text is the same as the
  title <b>Label</b>. <br>&nbsp;</dd>

<dt><b>Avoid intermediate composites.</b></dt>
<dd>Accessibility tools will read as far up the parent hierarchy of a widget
  with focus as possible. Be sure there are no widgets without text anywhere in the tree.<br>&nbsp;</dd>

<dt><b>Use read-only texts instead of labels.</b></dt>
<dd>A <b>Text</b> can be accessed using the keyboard and should be used if you want
  the information in a label to be accessible to keyboard navigation. Note that a
  label beside a text will be treated as a title and so if you have a title/value pair,
  it is only required that you make the value widget a <b>Text</b>.<br>&nbsp;</dd>

<dt><b>Read and understand the IBM checklist.</b></dt>
<dd>IBM provides a useful checklist for good accessibility at <a href="http://www.ibm.com/able/guidelines/software/accesssoftware.html">
http://www.ibm.com/able/guidelines/software/accesssoftware.html</a><br>&nbsp;</dd>

<dt><b>Assign mnemonics to all menus and menu items.</b></dt>
<dd>Ensure they are unique within a given menu. If a menu
  is dynamically composed from multiple plugins, it may be better to not assign
  mnemonics since conflicts cannot be avoided in general (e.g. the <b>File &gt; New</b>
  list, or <b>Window &gt; Show View</b> list)<br>&nbsp;</dd>

<dt><b>Assign mnemonics to all labels of controls in
dialogs / preference pages / property pages (e.g. buttons, check-boxes, radio
buttons, etc)</b></dt>
<dd>Ensure they are unique within the dialog. Be careful to
avoid collisions with the default buttons (e.g. Restore &amp;Defaults,
&amp;Apply in preference pages; &amp;Next, &amp;Back, &amp;Finish in wizards).
Do not assign mnemonics to OK and Cancel buttons. If you make OK the default
button of the shell, and Cancel is equivalent to closing the shell, then Enter
and Esc map to these by default. Generally doing something with Esc or Enter is
a bad idea.<br>&nbsp;</dd>

<dt><b>Ensure that controls that do not have labels are preceded by a label.</b></dt>
<dd>If a control does not have its own label (e.g. a text field), use a preceding label
ending with ':' and assign a mnemonic to it. Screen readers like JAWS will read this label
when the control has focus (see <b>Window &gt; Preferences &gt; General</b>)<br>&nbsp;</dd>

<dt><b>Avoid extra free-standing labels.</b></dt>
<dd>You cannot navigate to free-standing labels with the keyboard and screen readers
like JAWS skip these since they do not take focus<br>&nbsp;</dd>

<dt><b>Do not assign mnemonics to controls in the main window.</b></dt>
<dd>Do not put mnemonics on controls in the main window (other than main
menus and main menu items), even if it looks like a dialog (e.g. the form editors in
org.eclipse.ui.forms) as these will usually conflict with menu mnemonics<br>&nbsp;</dd>

<dt><b>Assign shortcut keys for frequently used functions (and <em>only</em> frequently used functions).</b></dt>
<dd>There are currently only two ways to hook shortcut keys in SWT:
<ul>
    <li>by setting an accelerator on a menu item in the
      main menu bar (they are ignored in context menus) -- JFace actions have
      support for this</li>
    <li>by hooking a key listener on a particular control
      (e.g. in the implementation of a view or editor)</li>
</ul>
Consult the table of Eclipse SDK shortcut keys, available within Eclipse from the <b>General &gt; Keys</b>
preference page, to avoid collision.<br>&nbsp;</dd>

<dt><b>Avoid Alt+{key}, Ctrl+Alt+{key} and Ctrl+Space+{key} combinations.</b></dt>
<dd><ul>
<li>Alt+{key} combinations may conflict with menu mnemonics</li>
<li>Ctrl+Alt+{key} combinations can conflict with entering special characters on international keyboards (alt Gr = Ctrl+Alt)</li>
<li>Ctrl+Space+{key} combinations can conflict with Ctrl-Space, used for mode switching in Asian languages.</li>
</ul></dd>

<dt><b>Try to save navigation context.</b></dt>
<dd>For example, in <b>Window &gt; Preferences</b>, we now remember
which page you had selected last. This avoids having to navigate through the
list each time<br>&nbsp;</dd>

<dt><b>Assign a specific person on the team to be responsible for accessibility on your project.</b></dt>
<dd>Everything that is important needs an advocate. Make sure that everyone on the team knows
that good accessibility is crucial, and is willing to give the person their full cooperation.<br>&nbsp;</dd>

<dt><b>Test for accessibility.</b></dt>
<dd>Have your team hold an occasional &quot;unplug your mouse day&quot; where they
try to use the product using keyboard only. If you are developing on Window, get a copy of
<a href="http://www.freedomscientific.com/">JAWS<font size="-1"><sup>TM</sup></font></a>
and ensure that your UI is usable with it<br>&nbsp;</dd>
</dl>

</body>
</html>
